add ability to indicate bad args #302
Conversation
|
@phliar @junchaoWu what do you folks think about adding this ability? I'm actually kind of on the fence about it. |
|
If we speak in HTTP codes, this would be replacing a 500 with a 400, which makes perfect sense. @mattgode Do you mean documenting which endpoints can return which errors? (I assume we do not actually want to export HTTP codes as part of the DOSA API.) |
|
@phliar the fact that they are http error codes is somewhat immaterial. I was suggesting the use of constants to indicate which codes should be sent over the wire to properly map to an error that is defined in DOSA . Specifically here I am referring to our use of http error codes in the YARPC connector. For example, there is an implicit contract where we know a 404 status code maps to a not found error but I think this connector export some error codes (they can still be http, it doesn't really matter) such that we can have a more explicit contract between gateway and YARPC client. |
|
|
There are instances where we'd like to be able to indicate to upstream connectors that the particular args they received were invalid (i.e. the request was incorrect). Having this error would allow us, for instance, to catch Cassandra specific errors and bubble them up to our gateway handler, which could then in turn properly encapsulate the error as a
BadRequestErrorinstead of an internal service error.I have some code serverside that I want to add to the Cassandra connector. This code has cassandra specific input validation and I'd like to be able to indicate to the handler that this error the cassandra connector is returning isn't the result of an internal server error, but rather that it was given some bad inputs.